我現在寫程式，有不少時間不是自己打字，是跟 Claude Code 對話出來的。

這句話講出來通常會收到兩種反應。一種是「所以你不用自己寫 code 了，爽」。另一種是「AI 寫的東西能信嗎」。

這系列想老實回答第二種人。

我不是要推銷工具。這陣子用下來，踩過的坑跟省下的時間差不多多。我想記的不是「AI 有多神」，是我這個寫了十幾年程式的人，每天怎麼判斷「這件事要不要交給它」「它說做完了我信不信」「錯的時候怎麼揪出來」。

會特別強調「資深」，不是要拿年資壓人。是因為我發現這件事對資深工程師反而比較難放心用。junior 可能覺得 AI 寫出來就是對的、跑得動就收工；但我們這種寫久的人，腦子裡有一堆「這裡通常會出事」的直覺，一開始很難忍住不自己動手改，也很難完全信任一個看起來很篤定、但其實不知道自己哪裡錯的東西。這系列想記的，是怎麼把這種直覺用得上，而不是被 AI 的自信蓋過去，也不是完全不信任它、什麼都自己重做一遍。

先講幾個我現在真的在用的判斷方式，之後每篇拆開講細節。

一個問題要讀超過三個檔案才答得出來，我幾乎不會自己動手找，直接丟給另一個 agent 去查。不是因為懶，是因為自己去翻檔案會把腦子塞滿，留不下空間做真正要判斷的事。我把自己定位成負責下決定的人，不是負責把所有資料讀一遍的人。這兩件事分開之後，工作效率差很多。

寫的人不能驗自己寫的東西。這句話聽起來像廢話，但我一開始也常常自己寫完看一眼就覺得「應該沒問題」。後來養成的習慣是：誰產出的，就一定換一個沒看過整個過程的人（或另一個全新的 AI session）去核對。這個習慣不是我天生謹慎，是被錯過的 bug 教會的。

「它說做完了」這句話，我現在不太信。做完的定義是我能一條一條指出當初講好的驗收條件在哪裡被滿足，不是「跑完最後一個指令」。這兩件事之間的落差，我踩過的次數比我想承認的多。它會很自然地把「我跑完了」講得跟「我做對了」一樣篤定，兩者其實常常不是同一件事。

同一件事如果連錯兩次，我不會再用同樣的講法求它重試第三次。我會換一個更強的模型，或直接換一種做法。方法不對，多試幾次只是把同一個牆撞出更深的凹痕，不會突然通。這聽起來簡單，但我自己也是撞了不少次牆之後才把它變成習慣，不是一開始就懂。

還有一條是紅線：寧可讓它停下來問我，也不准它為了把事情做完而編。缺一個數字、一段對話、一件事，語言模型很自然就會生一個聽起來合理的出來補上。這不是在騙人，是它的天性，但後果一樣麻煩，而且越信任它的人越容易被這種天性坑到，因為你根本不會去查一個「聽起來很合理」的東西。

這些不是我一次想通的，是踩了不少次才慢慢寫下來的。接下來這系列，我會拿真實在做的事，像是寫功能、抓 bug、code review、跟好幾個 AI agent 分工，記錄我怎麼用、哪裡判斷錯、後來怎麼調整。

我預計會寫到：一件工作怎麼拆給不同角色做、怎麼抓出它編出來的東西、同一個錯誤連續發生時我怎麼反應、還有到現在為止哪些判斷我還是堅持自己來、沒打算交出去。

做完的就寫做完，沒驗的就寫沒驗，搞砸的也照樣寫。